1 SYSTEM AND METHOD FOR POPULATING FORMS WITH 

2 PREVIOUSLY USED DATA VALUES 

3 

4 TECHNICAL FIELD 

5 This invention relates generally to computer-implemented processing of data entry 

6 forms, such as Internet web pages containing form fields. More particularly, the invention 

7 provides a method and apparatus for automatically populating data fields in forms across 

8 different applications and web sites using data values previously entered by a user. 

9 BACKGROUND OF THE INVENTION 

10 Computer systems conventionally display forms with fields into which a user enters 



1 1 information such as a name, birth date, password, and the like. Modern Internet browsers 

12 display forms by rendering Hyper Text Markup Language (HTML) on web pages to generate 

13 fields that can be populated by a user. Web sites that accept shopping orders from on-line 

14 customers, for example, generate forms requiring that a customer enter the customer's name, 

15 address, telephone number, and credit card information. Usually, the user must repeatedly 

16 enter this information each time the site is visited. Although information entered by the user 

1 7 is stored on the web site, the form does not retain the information for future use if the web site 

18 is revisited. 

1 9 Some web sites can recognize previous customers and thus avoid re-prompting for the 

20 same information on a subsequent visit. Nonetheless, if the user visits a new web site that he 

21 or she has never before visited, the same information must be re-entered on a different form 

22 generated by the different web site. Much of the information requested on these forms is 

23 redundant or readily available from other sources (e.g., name, address, date of birth), yet the 

24 creators of different forms generally have no easy way to share information previously entered 

25 by the user on an earlier form. Privacy issues have thwarted many potential solutions to this 

26 problem, and it is cumbersome for web site designers to include special logic on their web site 

27 to recognize previous visitors to the site. 



28 So-called "cookies" (small data files stored by a web site on the user's local computer) 

29 are sometimes used to retain information locally that can be recalled later by a web site that 

30 the user has previously visited. Such "cookies" however, vary widely from site to site, and 

3 1 require cumbersome programming logic on each web site to implement them. Moreover, users 
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1 can block the storage of these cookies, and users may be generally suspicious of their use by 

2 untrusted web sites. In addition, conventional web browsers will not transmit a given cookie 

3 to web servers with different secondary domains (e.g., a cookie written by a. com will not be 

4 shared with a server from b.com). 

5 One attempt to solve some of these problems was a prior art feature embedded in the 

6 Microsoft Internet Explorer 4.0 product known as a "profile assistant." This feature made it 

7 easier for web sites to retrieve registration and demographic information from users who had 

8 previously provided that information. Frequently used information such as user name, 

9 address, and the like was stored securely in protected storage on the client computer. Web 

1 0 servers could request to read this information, but it was shared only if users gave their consent 

11 in a pop-up request box each time a site was visited. 

12 While the profile assistant provided a potential solution to the aforementioned 

1 3 problems, in practice it has not enjoyed widespread success. For example, it required that each 

14 web site write script to request information from the user's stored information. If the user 

15 declined to grant permission to share the information, the solution was effectively thwarted. 

16 Moreover, the solution was limited to certain predefined fields that were commonly used 

17 across different web sites, with no easy way to add new fields. It was also inconvenient and 

18 time consuming for the user to complete a full profile and store it on the user's machine. 

19 Finally, some users viewed the function as intrusive because it required immediate user input 

20 to confirm that the feature should be enabled each time a web site was visited. 

21 A prior art data schema known as the "vCard" schema has been used for certain 

22 frequently referenced data fields across application programs. This schema established certain 

23 standardized field identifiers that were to be used for the same data fields, and was intended 

24 to facilitate the transfer of personal profile information among applications. For example, the 

25 following is an example of a vCard: 

26 begimvcard 

27 n:Doe, John 

28 tel;cell:415 555 1212 

29 tel;fax:415 555 1212 

30 tel;work:415 555 1212 
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1 x-mozilla-html:FALSE 

2 org:One & Co. 

3 version:2.1 

4 email;internet:cathy@oneandco.com 

5 adr;quoted-printable:;;247 4th St. #105=0D=0A;Oakland;Ca.;94607;USA 

6 x-mozilla-cpt:;3 

7 fii: John 

8 end:vcardwas 

9 Using this schema, specific fields can be identified regardless of the form or 

10 application program into which the user's name was to be entered. (The user would most 

1 1 likely only see a label such as "First Name.") This schema does not, however, solve the 

12 aforementioned problems. As one example, it is difficult to force millions of web sites to 

13 conform to standard field identifiers or to retrofit existing web pages to the existing schema. 

14 Moreover, as new fields are introduced, universal agreement must be reached on what those 

1 5 fields represent and what their identifiers will be. 

16 The prior art provides tools to suggest previously used values to a computer user when 

17 prompting the user for information. For example, some e-mail programs suggest possible 

18 recipient names in the "to" field which match previously stored user names. When the user 

1 9 types the first character of a recipient's name, a possible choice that matches the first character 

20 appears in the field. As another example, well-known Internet browsers provide a user with 

21 a pull-down menu of choices in an Internet browser address field, such that the user can review 

22 previously used web site addresses in order to select an address. 

23 These conventional techniques, however, suffer from many of the same disadvantages 

24 as the aforementioned solutions. The application program itself (i.e., the e-mail program) must 

25 be specially modified to support the feature, and previously used field values cannot be shared 

26 among other application programs on the same computer unless those applications are also 

27 modified. Moreover, all application programs would need to adopt standard field identifiers 

28 in order for the scheme to work properly. 

29 Internet web pages containing form fields create special problems, because each web 

30 site defines the format and behavior of its own forms, and there is no easy way to share or 
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1 suggest previously entered data values across different web sites or servers. Moreover, because 

2 of privacy concerns, sharing previously entered form values for different web sites may be 

3 undesirable or even impossible in many cases. 

4 In summary, user interfaces such as those provided by application programs and web- 

5 based forms frequently request the same or similar information from a user. Challenges posed 

6 by this problem include: (a) determining how to decrease redundant data entry across form 

7 fields (whether the same form or a different form containing a common field); (b) decreasing 

8 the redundant data entry without requiring changes to the forms themselves; (c) encouraging 

9 the adoption of standard field descriptors across applications, web sites and web pages; and 

10 (d) preventing unauthorized access to information that has been entered by a user. 

11 SUMMARY OF THE INVENTION 

12 The present invention overcomes many of the foregoing problems by providing a 

13 method and apparatus for learning data values from a user over time as the user enters values 

14 into fields on a form such as a web page form. In one embodiment, an Internet web browser 

1 5 includes code that that suggests previously used data values for any form text field that is the 

1 6 same as or similar to a previously used form text field. This feature can take advantage of the 

1 7 fact that web page authors frequently use the same or similar names for fields when prompting 

1 8 for the same information (e.g., "phone" when requesting a telephone number). Any browser- 

19 based application program (or any form retrieved from a web site using the browser) can gain 

20 limited access to previously used field values without compromising security or privacy. The 

2 1 invention can be implemented without modifying any of the application programs or web sites 

22 that contain forms. 

23 In one embodiment, software in a web browser associates field names across different 

24 Universal Resource Locators (URLs), so that when a user enters a value into a field (e.g., 

25 username) at a first web site, that same value can be automatically suggested when the user 

26 displays a different form on a different web site that uses the same field name. The more web 

27 sites that are visited by the user, the more the software learns field values and is able to suggest 

28 likely choices for field values. For security reasons, field values are preferably not stored in 

29 the application program or on the target web site, but are instead stored locally on the client 

30 computer or at a trusted web site known to the browser. 
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1 Some embodiments of the invention prevent web sites from surreptitiously discovering 

2 suggested values by forcing the user to initiate some action (e.g., hitting a key or clicking a 

3 mouse) before a data value for a field is suggested, and by only writing data into the field 

4 when the user has selected one of the suggested values. Certain field values (e.g., passwords 

5 and credit card numbers) can be treated differently for even more security. 

6 Heuristics can be used to identify and suggest values for fields. For example, a "most 

7 frequently used' 5 value for a particular field can be suggested as a first choice rather than the 

8 last used value. Additionally, synonyms can be provided to correlate similar field names (e.g., 

9 "name," "username," "your name," etc.) across different forms. Bayesian inference functions 

10 can also be used to help match previously entered data values across different field names. 

1 1 The principles of the invention can also be used to share data across browser- 

12 compatible applications. For example, the user of a newly created application that requires 

13 entry of a zip code would automatically be provided with a suggested zip code that was 

14 previously used with a totally different application weeks earlier, even though the newly 

15 created application had no knowledge or special code to handle previously entered values. 

16 The invention can also be made compatible with the existing vCard schema standard, 

17 such that standard fields in that schema (e.g., vCard.Email) are correlated with fields on 

1 8 different forms. Previously used form field values can be stored in a protected storage area 

19 to protect them from snooping. In one embodiment, previously used field values can be can 

20 stored at a predetermined trusted web site, such that a user could access the previously used 

21 values even when using a different computer (e.g., a home computer instead of the office 

22 computer). 

23 BRIEF DESCRIPTION OF THE DRAWINGS 

24 FIG. 1 shows a conventional general-purpose computing environment that can be 

* 

25 employed in various embodiments of the invention. 

26 FIG. 2 shows a distributed web-based system employing various principles of the 

27 invention. 

28 FIG. 3 shows various steps that can be performed in accordance with one or more 

29 embodiments of the present invention. 

30 FIG. 4A shows one possible technique for displaying a list of choices for a field data 
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1 value and selecting one of the displayed choices. 

2 FIG. 4B shows a second technique for displaying a list of choices for a field data value 

3 and selecting one of the displayed choices. 

4 FIG. 4C shows a third technique for displaying a list of choices for a field data value 

5 and selecting one of the displayed choices. 

6 FIG. 4D shows a fourth technique for displaying a list of choices for a field data value 

7 and selecting one of the displayed choices. 

8 FIG. 5A shows one possible technique for providing options that permit a user to 

9 specify which data values should be suggested and stored. 

10 FIG. 5B shows one possible technique for prompting a user with an option to 

1 1 automatically remember a password for a future form. 

12 FIG. 6 shows various sources of information from which previously stored data values 

1 3 can be retrieved and mapped. 

14 DETAILED DESCRIPTION OF THE INVENTION 

15 FIG. 1 is a schematic diagram of a conventional general-purpose digital computing 

16 environment that can be used to implement various aspects of the invention. Computer 100 

17 includes a processing unit 110, a system memory 120, and a system bus 130 that couples 
. 18 system components including the system memory to the processing unit 110. The system bus 

19 130 may be any of several types of bus structures including a memory bus or memory 

20 controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The 

21 system memory includes read only memory (ROM) 140 and random access memory (RAM) 

22 150. 

23 A basic input/output system 160 (BIOS), containing the basic routines that help to 



24 transfer information between elements within the computer 100, such as during start-up, is 

25 stored in ROM 140. Computer 100 also includes a hard disk drive 170 for reading from and 

26 writing to a hard disk (not shown), a magnetic disk drive 1 80 for reading from or writing to 

27 a removable magnetic disk 190, and an optical disk drive 191 for reading from or writing to 

28 a removable optical disk 192 such as a CD ROM or other optical media. The hard disk drive 

29 170, magnetic disk drive 180, and optical disk drive 191 are connected to the system bus 130 

30 by a hard disk drive interface 192, a magnetic disk drive interface 193, and an optical disk 
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1 drive interface 194, respectively. The drives and their associated computer-readable media 

2 provide nonvolatile storage of computer readable instructions, data structures, program 

3 modules and other data for the personal computer 100. It will be appreciated by those skilled 

4 in the art that other types of computer readable media which can store data that is accessible 

5 by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli 

6 cartridges, random access memories (RAMs), read only memories (ROMs), and the like, may 

7 also be used in the exemplary operating environment. 

8 A number of program modules can be stored on the hard disk, magnetic disk 190, 

9 optical disk 192, ROM 140 or RAM 150, including an operating system 195, one or more 

10 application programs 196, other program modules 197, and program data 198. Any of the 

1 1 inventive principles described herein can be implemented in software and stored on any of the 

12 aforementioned storage devices. 

13 A user can enter commands and information into the computer 100 through input 

14 devices such as a keyboard 101 and pointing device 102. Other input devices (not shown) may 

15 include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other 

16 input devices are often connected to the processing unit 110 through a serial port interface 106 

17 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel 

18 port, game port or a universal serial bus (USB). A monitor 107 or other type of display device 

19 is also connected to the system bus 130 via an interface, such as a video adapter 108. In 

20 addition to the monitor, personal computers typically include other peripheral output devices 

21 (not shown), such as speakers and printers. 

22 The computer 100 can operate in a networked environment using logical connections 

23 to one or more remote computers, such as a remote computer 109. Remote computer 109 can 

24 be a server, a router, a network PC, a peer device or other common network node, and 

25 typically includes many or all of the elements described above relative to computer 100, 

26 although only a memory storage device 111 has been illustrated in FIG. 1 . The logical 

27 connections depicted in FIG. 1 include a local area network (LAN) 112 and a wide area 

28 network (WAN) 113. Such networking environments are commonplace in offices, enterprise- 

29 wide computer networks, intranets and the Internet. 

30 When used in a LAN networking environment, the computer 100 is connected to the 
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1 local network 112 through a network interface or adapter 114. When used in a WAN 

2 networking environment, the personal computer 100 typically includes a modem 1 15 or other 

3 means for establishing a communications over the wide area network 113, such as the Internet. 

4 The modem 1 1 5, which may be internal or external, is connected to the system bus 130 via the 

5 serial port interface 106. In a networked environment, program modules depicted relative to 

6 the personal computer 100, or portions thereof, may be stored in the remote memory storage 

7 device. 

8 It will be appreciated that the network connections shown are exemplary and other 

9 means of establishing a communications link between the computers can be used. The 

10 existence of any of various well-known protocols such as TCP/IP, Ethernet, FTP, HTTP and 

1 1 the like is presumed, and the system can be operated in a client-server configuration to permit 

12 a user to retrieve web pages from a web-based server. Any of various conventional web 

13 browsers can be used to display and manipulate data on web pages. 

14 F^G. 2 shows a web-based distributed system employing various principles of the 

15 present invention. As shown in FIG. 2, a client computer 204 is coupled to a first web server 

16 201, a second web server 202, and a third web server 203 through a network such as the 

17 Internet. Client computer 204 includes a conventional web browser 206 that has been 

1 8 modified in accordance with the principles of the present invention. As is conventional, the 

19 user of client Computer 204 can retrieve web pages from web servers through the Internet 

20 using HTTP protocols, and can display web pages using HTML syntax. Application programs 

21 that operate within the context of modified web browser 206 will automatically obtain the 

22 benefits of the inventive principles described herein without modification. Alternatively, any 

23 application program can be created or modified to operate according to the inventive 

24 principles. 

25 As shown in FIG. 2, each web server has associated therewith a Universal Resource 

26 Locator (URL) that uniquely identifies the server to client computers on the Internet. For 

27 illustration purposes, first web server 201 has a URL of http://www.one.com; second web 

28 server 202 has a URL of http://www.two.com, and third web server 203 has a URL of 

29 http://www.three.com. Web servers are sometimes referred to as "web sites," and those terms 

30 are used interchangeably herein. Each web site may contain one or more web pages that can 
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1 be linked and retrieved using conventional protocols. 

2 One type of web page permits data to be entered using form fields. As shown in FIG. 

3 2, web site 201 includes a first form 250, and second web site 202 includes a second form 260. 

4 Each form includes a plurality of data entry fields that include a field label (e.g., name, 

5 address, phone), a field identifier (usually hidden from view), and a corresponding display 

6 region into which the user can type information when the web page is displayed using a 

7 conventional web browser. For example, an on-line shopping service may require that a 

8 customer enter his name, address and telephone number to process an order. Similarly, a 

9 government agency may require that a citizen enter his or her name, address, and date of birth. 

10 The field label corresponds to what the user will actually see on the display, while the field 

1 1 identifier or field name is frequently not displayed but permits an application program or web 

12 browser to identify the field. For example, a field label for a user's name might be displayed 

13 as "NAME," while the field identifier, visible to only the underlying software, might be 

14 "user_last__name." Of course, it is possible to use the same value for the field label and the 

15 field identifier, and it may also be possible to use one without the other, as long as the field 

1 6 can be identified. 

17 As shown in FIG. 2, forms 250 and 260 require overlapping information; namely, the 

18 name and address of the person filling out the form. After the user has entered data into the 

19 fields, web browser 206 submits the form with the entered values to the web site from which 

20 the form was generated. Some web sites employ "script" executed by browser 206 to perform 

21 various functions on client computer 204 in connection with the processing of forms. 

22 In accordance with one aspect of the present invention, data values entered by the user 

23 are extracted and stored for future use with different forms having fields with the same or 

24 similar identifiers. For example, the first time that the user of client computer 204 visits web 

25 site 201 and enters his name, address, and telephone number into form 250, modified web 

26 browser 206 associates the values entered by the user with the field identifiers and the URL 

27 for the web site and stores them into a data structure 207 for future use. Consequently, when 

28 the user visits different web site 202 and displays form 260, modified web browser 206 

29 recognizes that some of the field identifiers used in form 260 are the same as or similar to field 

30 identifiers associated with a previously used form, and the values associated with those fields 
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1 are retrieved and suggested to the user at the time he or she begins to fill out form 260. 

2 Various techniques for prompting the user with suggested form field values are 

3 possible, and the invention is not intended to be limited to any particular approach. As shown 

4 in FIG. 2, one possible technique involves displaying a "pop-down" or "drop-down" list 205b 

5 below a field data entry region 205a after the user types a first character in the field. For 

6 example, assuming that the user has displayed form 205 on client computer 204 containing a 

7 field identified as "name," the user begins by typing "J" to start his name, Joe Smith. 

8 Immediately after the letter "J" is received in the form field, web browser 206 displays pop- 

9 down list 205b suggesting previously used values for fields having the same or a similar name. 

1 0 The user can move an up/down arrow key or mouse to select from the various choices, and 

1 1 can press a key such as the return key to consummate the selection. It will be appreciated that 

12 the list can be displayed "up" or "sideways" instead of "down" as illustrated, and those 

13 variations are expressly within the scope of the term "pop-down" as used herein. 

14 As shown in FIG. 2, the exemplary user has previously visited three web sites: 

15 one.com, two.com, and x.com, and at each site has entered a value in a field identified as 

16 "name." Upon entering a value in the field identified as "name" at each site, modified web 

17 browser 206 stores in data area 207 a record of the value used, the field identifier, and the URL 

18 of the web site on which it was entered. Consequently, when the user again displays a form 

19 with the field identified as "name," modified web browser 206 recognizes the matching field 

20 identifier from previously visited web sites and suggests to the user the previously used values. 

21 Modified web browser 206 may comprise any of a number of presently available web 

22 browsers that are modified in accordance with the inventive principles described herein. Many 

23 different approaches are of course possible, depending on the type of web browser and the 

24 design features available for the browser. One possible set of functions in the modified 

25 browser includes a field matching function 206a, heuristics function 206b, and a prompter and 

26 extraction function 206c. 

27 Briefly, field matching function 206a searches through data store 207 when a field is 

28 selected to locate matching (identical or closely related) field identifiers, corresponding URLs, 

29 and previously used field values according to one or more heuristics determined by heuristics 

30 function 206b. (Matching by URLs may not be necessary or desirable in all cases, as 
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1 explained below). After the user has entered a value for a field or selected a previously used 

2 value, field matching function 206a stores the value into data store 207 for future use, along 

3 with the URL and field identifier. 

4 Heuristics function 206b can be employed to generate suggestion lists according to 

5 various heuristics that can optionally be user-controlled. For example, suggestions can be 

6 displayed in priority order based on the source from which they were obtained; by most- 

7 recently-used values; by similarity of field name or URL; or any other measure desired. 

8 Various heuristics are described in more detail with reference to FIG. 6. 

9 Prompter and extraction function 206c generates and displays prompt list 205b 

10 according to the first letter typed in by the user, and stores values entered by the user into data 

1 1 store 207. One reason for requiring that the user type a first letter (or click a mouse button or 

12 make some similar user input) before any data values are released to the form (e.g., copied into 

13 data entry region 205a) is that a nefarious web site operator may be able to extract data values 

14 from data entry region 205a as soon as data is present in the region, which might cause 

15 suggested values (e.g., a telephone number) to be surreptitiously captured even if the user 

16 chooses not to enter a value into the field. For example, script on a web page could insert a 

17 character, wait for a change notification, and try to discern what suggested values were 

18 provided. Nonetheless, it is not necessary to implement the feature in this manner and it is of 

19 course within the scope of the invention to provide a suggestion list or suggested value without 

20 input at all by the user. Other variations on this approach are described in more detail below. 

21 Requiring a mouse click or key press would not require that the user navigate through the 

22 form using the mouse. 

23 The values in data store 207 can be stored in encrypted form in a protected area in 

24 client computer 204. As explained in more detail herein, the values can be correlated or 

25 combined with data from other sources, such as values used by the profile assistant, an entry 

26 for the user in an operating system address book, commonly used field identifiers, or field 

27 names from the vCard schema. 

28 Instead of storing data values in area 207, previously used form data values can be 

29 stored on a trusted web site known to browser 206 or selected by the user. As shown in FIG. 

30 2, for example, web site 203 contains a storage area 208 for storing previously used data 
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1 values for a plurality of users. This feature would permit a user that has both a home computer 

2 and an office computer to automatically be prompted with field suggestions that were made 

3 from either computer. In other words, web browser 206 would know (based on the log-in 

4 name, for example) that the user's previously stored data values on web site 203 should be 

5 used to suggest form values, even if the user had never previously used client computer 204 

6 to enter data on any forms. 

7 Reference will now be made to FIG. 3, which shows various steps that can be 

8 performed for carrying out the principles of the present invention. It is assumed that the user 

9 has selected a form for display (e.g., an HTML-compatible web form, or an application form 

10 on which multiple fields are displayed), and has placed the cursor in one of the fields on the 

1 1 form. It is also assumed that these steps are performed in conjunction with modified web 

12 browser 206 such as that shown in FIG. 2, or a similarly modified application program on a 

13 client computer. It will be appreciated that although the steps are shown in sequential order, 

14 the inventive principles can be carried out using object-oriented programming techniques with 

1 5 event-driven processing. 

16 In step 301, processing begins when the user hits a key, such as typing the first 

1 7 character of a field value, or by hitting the space bar or down arrow. For example, if the field 

18 is "name" and the user's proper name is "Joseph," the user could hit the "J" key on the 

19 keyboard. Upon detecting a keystroke, software identifies the field in which the cursor is 

20 active (step 302). In step 303, a determination is made as to whether the field is one of a 

21 special category, such as passwords, credit card numbers, and the like. If so, then special 

22 handling is performed in step 304, which may cause some or all of the remaining steps to be 

23 skipped for that field. (See detailed description below with reference to FIG. 6). 

24 Assuming that no special handling is required for the field, then in step 305 the field 

25 identifier for the field in which the cursor is active is matched to previously stored values for 

26 the same or a heuristically similar field to identify a list of one or more potential matches. As 

27 explained previously, this field matching step may encompass identifying the most recently 

28 used value for an identically named field or a similarly named field, and may generate one or 

29 more values used for different web sites, as illustrated in FIG. 2. Other matching techniques 

30 are possible; some of these are described below with reference to FIG. 6. 
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1 In step 306, a list of possible choices is displayed to the user, preferably but not 

2 necessarily in a pop-down menu list of the type shown in FIG. 2. Additionally, a "best match" 

3 choice can be suggested in the field display area 205a (FIG. 2), overwriting the user's solitary 

4 keystroke with the suggested field value (i.e., replacing "J" with "JOSEPH"), or it may be 

5 placed at the top of a list of suggested values. 



6 In step 307, the user selects a value from the list of choices by indicating that the 

7 suggested value is correct, or by navigating down the list of choices using a mouse, up/down 

8 arrow, or other similar technique. (If none of the suggested choices is correct, the user will 

9 enter a new value into the data entry region 205a). Or, the user could continue typing, with 

10 the list being refreshed after each pause in the user's keystrokes. (Although not specifically 

1 1 shown in FIG. 3, as the user continues to type, the list can be refreshed between steps 306 and 



12 307 to display choices matching the additional characters typed). After the user has selected 

13 or entered a value, the field identifier, the selected value, and the URL of the web site (if 

14 applicable) for the presently displayed form is stored for future use, such as in data store 207 

15 of FIG. 2. Thereafter, the user navigates to the next field and processing begins on that field 

16 in step 301. Other features can also be provided, such as automatically resizing the list of 

17 choices to accommodate an ideal width and height for the choices displayed, and tying the list 

18 to the page so that if the user scrolls the page the list scrolls with the page. 

19 It will be appreciated that there are many different ways of implementing the steps 

20 described above. For example, it is not necessary to require that the user hit a key before 

21 suggesting possible choices and inserting a data value into the field. However, as explained 

22 previously, requiring such a keystroke or other user-initiated action (such as voice input or the 

23 like) to prevent script on the page from impersonating the user may provide better 

24 security .Moreover, there are many ways of permitting the user to select choices and navigate 

25 among fields, such as using a tab key, up/down arrows, mouse clicks, and the like. Moreover, 

26 it may be desirable to give the user additional choices, such as affirmatively indicating whether 

27 a particular field value should be stored for future use. 



28 FIGS. 4A through 4D show several different techniques for prompting a user with 

29 possible field values, selecting one of the values, and storing the selected value for future use. 

30 Beginning with FIG. 4A, a portion of a form is shown, including a field label 401 and 
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1 a field data entry region 402. The user is presumed to have typed the first letter U J" 

2 corresponding to her name, and a pop-down, scrollable list 403 is immediately displayed with 

3 a list of possible choices for inserting into data entry area 402. As explained previously, these 

4 choices can be determined and displayed according to various heuristics. 

5 A corner resizing tab 405 can be used to expand the displayable area of the list beyond 

6 the three choices shown in FIG. 4A. The user can scroll down through the list using an 

7 up/down arrow or mouse, and can select the suggested or highlighted choice by pressing a key 

8 such as the tab key or the return key. Additionally, a checkbox 404 allows the user to change 

9 the default decision as to whether this field should be stored for future use. In this manner, 

10 the user can choose to have certain fields stored for future use on a field-by-field basis. As one 

1 1 example, the user may prefer to prevent his or her telephone number from being stored for 

12 future use, while allowing his name, address, and e-mail address to be stored for future use. 

13 In one embodiment, drop-down list 403 appears after the user enters the first character 

14 of a data value in form data area 402. The user will then have the opportunity to review the 

15 possible choices, which may be limited to previously used values for that field that begin with 

16 the same character. Alternatively, instead of typing the first letter, the user can press the 

17 "down" arrow key, which will cause the pop-down list to appear with suggestions for that 

18 field. With this approach, the user can, for example, fill out a zip code field without typing 

19 a single number (i.e., merely hitting the down arrow key will cause a list with the person's 

20 previously used zip code to appear). In one embodiment, the pop-down list feature may be 

21 limited to single-line edit boxes to prevent matching on such fields as e-mail messages. 

22 Various methods of navigating through the list are also possible. The user can begin 

23 typing, causing the list to be narrowed down to those choices that continue to match the 

24 succeeding characters entered. Alternatively, the user can click the down arrow to view a list 

25 of all likely choices for that particular field. Another approach is to display the pop-down list 

26 if the user clicks on the field entry area 402 with the mouse. Once the list is shown, the user 

27 can use the mouse to select an entry or use the arrow keys to navigate through the list. To 

28 select the item from the keyboard, the user can hit return or tab. The tab key can also be used 

29 to advance to the next field. Once the user has finished the form, hitting return while in a field 

30 data entry area box will submit the form and store any form values entered for future use. 
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The escape key can be used to make the drop-down list disappear (if it is shown) and 
clear any values in the data entry field. Hitting the escape key while the cursor is in the data 
entry area can delete the text, or the delete key (or backspace key) can be used to erase one 
character at a time. Using the delete/backspace keys can cause the list to update as the user 
types, since the text in the field changes. 

Various methods of controlling the drop-down list and specifying choices are possible, 
with the following illustrating one method of displaying and controlling the various choices 



in the drop-down list: 



USER ACTION 


CURSOR IN 
DATA ENTRY 
AREA, NO DROP- 
DOWN SHOWING 


CURSOR IN DATA 
ENTRY AREA, 
DROP-DOWN 
SHOWING 


CURSOR IN 
DROP-DOWN LIST 


TAB 


advances to next field 


advances to next field 


selects item, 
advances to next 
field 


DOWN 
ARROW 


displays drop-down 
list 


moves cursor into 
drop-down list 


moves down through 
list of choices 


RETURN 


submits the form and 
stores any entered 
values 


submits the form and 
stores any entered 
values 


selects item from 
list, returns cursor to 
data entry area, 
closes drop-down 


ESCAPE 


deletes text from data 
entry area 


drop-down disappears 


drop-down 
disappears; cursor 
returns to data entry 
area 


DELETE 


deletes one character 
from data entry area 


deletes one character 
from data entry area 


deletes selected 
entry from list 
permanently 



It may be desirable to provide indications to the user that the suggested choices are 
retrieved from the user's own computer rather than from the web sites visited. To that end, 
displaying a checkbox 404 (FIG. 4A), indicating that it is the Internet browser that is storing 
this field, can help reinforce this message. 

FIG. 4B shows a slightly different variation on the approach discussed above. As seen 
in FIG. 4B, a padlock display item 406 is shown at the bottom of the drop-down list. When 
the user clicks on this padlock, a choice bar 407 pops into view, permitting the user to 
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1 affirmatively indicate that the values in this field should be stored or not stored. Thereafter, 

2 the word "Autosuggest" can be displayed in area 408 as a reminder that data values for this 

3 field are being stored for future use. 

4 FIG. 4C shows yet another variation on this approach, which includes a checkbox 409 

5 permitting the user to affirmatively indicate that the values for the field should not be 

6 remembered for future use. In this manner, the user can selectively indicate that certain fields 

7 (e.g., passwords, telephone numbers, and the like) should not be stored for future use, while 

8 other more general information (e.g., name, address, and the like) can be stored for future use. 

9 FIG. 4D shows yet another variation on the foregoing approaches. As shown in FIG. 

10 4D, a special "X" indicator is displayed at the bottom of the drop-down list. Clicking on this 

1 1 "X" causes the drop-down list to disappear. 

12 A function can be provided which permits the user to delete items from the list of 

13 suggestions. For example, if the user types in "J", a suggestion list of "Jane", "John", and 

14 "Joe" might appear. If the user highlights and deletes "John", that choice would not longer 

15 appear on the list of suggestions. 

16 FIG. 5 A shows one possible approach for setting options in a web browser, so that the 

17 user can control at a global level the situations in which field values will be automatically 

18 suggested. As shown in FIG. 5 A, the user can indicate that he or she should be prompted 

19 before saving passwords. FIG. 5B shows another variation on this approach which allows the 

20 user to specify that passwords should be treated in a special manner. Providing the user with 

21 advance warning of this feature can help alleviate any concerns that the values are being 

22 surreptitiously stored by web site operators. 

23 The order in which entries are displayed in a pop-down list can be varied as desired. 



24 For example, if there is a previously stored field identifier that exactly matches a field on a 

25 form that the user is currently viewing, any data value associated with the previously stored 

26 field identifier can be suggested as a first choice. (If multiple data values are stored, they can 

27 be matched by URL, such that values from a previously visited web site would be displayed 

28 first). Alternatively, if a field identifier is not found in any previously stored data, the field 

29 identifier can be compared to one of a predetermined set of "common names" (e.g., name, 

30 address, telephone, phone, or similar subcombinations thereof such as addr) for which a 
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1 known value exists. Similarly, a field identifier can be compared to a user profile stored on 

2 the client computer to find a match. 

3 Another possible approach is to increment a one-up counter every time a previously 

4 stored field value is re-used, such that if there are several possible choices for a field, values 

5 will be suggested in the order of most frequent use. Alternatively, field values can be 

6 suggested in order of most-recently-used values. 

7 FIG. 6 shows various ways of suggesting field values based on previously stored 

8 values, including static and heuristically determined field mappings. As shown in FIG. 6, a 



9 heuristics function 601 (corresponding to heuristics function 206b of FIG. 2) is coupled to 

10 various data stores including history file HISTORY, a user profile file USER PROFILE, 

1 1 common names file COMMON NAMES, vCard schema file VCARD SCHEMA, and a field 

12 correlators file FIELD CORRELATORS. Additionally, a password processing function 603 

13 and credit card processing function 602 can be provided. 

14 In FIG. 6, history file HISTORY contains previously stored field identifiers, URLs, 

15 and field values for fields that the user previously entered. For example, as shown in FIG. 6, 

16 the user has entered values for two different fields ("name" and "firm") across six different 

17 web sites. When the user visits web site one.com for a second time and encounters a form 

18 having a field identifier of "name", the user can now be prompted with the suggestion of "Joe" 

19 for that field. Additionally, because the same field identifier was used (with slightly different 

20 values of "Joseph" and "J. Smith") at two other web sites, those values could also be suggested 

21 to the user. 



22 Similarly, when the user visits a new web site not previously visited, any fields on that 

23 site having field identifiers of "name" or "firm" could be associated with the stored values 

24 from the earlier visited web sites, and heuristics function 601 could suggest any of the values 

25 previously stored from those web sites. Where multiple values were previously stored, they 

26 can be displayed in order of most- frequently-used, last-used, alphabetical, or any other order. 

27 Additionally, where an exact match is not available, synonyms or close matches can 

28 be provided. Thus, for example, if a field identified as "username" is encountered, heuristics 

29 function 601 can determine that the field is similar to field identifier "name" in HISTORY, 

30 and the previously entered values for that field can thus be suggested. After the user selects 
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1 a suggested value or enters a new value, history file HISTORY is updated to reflect the new 

2 information. (If the user had selected "do not store" for that field, however, this function 

3 would be bypassed). 

4 The principles of the present invention can be implemented in conjunction with many 

5 different types of field information, including previously stored USER PROFILE information 

6 (such as might have been previously entered using the profile assistant); commonly used 

7 names file COMMON NAMES (e.g., a list based on commonly used field identifiers found 

8 on Internet web pages); and the conventional VCARD SCHEMA, which identifies specific 

9 fields that conform to the vCard standard. (The vCard field identifiers in FIG. 6 differ slightly 

10 from those in the prior art vCard convention in that more descriptive string identifiers are 

1 1 mapped to the vCard fields. For example, vCard string "fh" is mapped to "vCard.FirstName" 

12 as the corresponding HTML input field name identifier.) Heuristics function 601 can specify 

1 3 one or more of these data sources from which suggested field values will be retrieved, and can 

14 store new values in some of these data sources. The data sources illustrated in FIG. 6 are 

1 5 intended to be illustrative only. Many different sources of data can be used, and the structure 

16 and arrangement of the data can vary without departing from the principles of the invention. 

17 As shown in FIG. 6, various mappings between field identifiers can be established 

18 statically and/or dynamically by heuristics function 601 as a user fills out forms over time. For 

19 example, COMMON NAMES may include three commonly used field identifiers for a user's 

20 name: "name", "your name", and "first name." All of these values can be statically mapped 

21 to VCARD SCHEMA field identifier "vcard.firstname," and to USER PROFILE field 

22 identifier "name", so that when any one of these field identifiers is encountered, all of the 

23 values associated with any of them can be automatically suggested. Thus, for example, a form 

24 that contains a field identifier "vcard.firstname" would be mapped to fields "name", 

25 "yourname", and "firstname" in COMMON NAMES, which would also be mapped to USER 

26 PROFILE field identifier "name" (which would suggest the value "Joe"). Additionally, 

27 because field identifier "name" in USER PROFILE is identical to three field identifiers 

28 contained in HISTORY, the values "Joe", Joseph", and "J. Smith" could also be suggested. 

29 (It may be desirable to eliminate duplicate choices "Joe" from the list). Consequently, a web 

30 site that generated a form with a field identified as the standard vCard.FirstName would cause 
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1 a pop-down list to suggest "Joe", "Joseph", and "J. Smith" to the user, even though that web 

2 site had no prior knowledge of any of these prior values. 

3 Similarly, a web site that generates a form with the field identifier "firm_name" would 

4 generate a pop-down list automatically suggesting previously used values "Acme" and "Big 

5 Co." in HISTORY as follows: "firrnname" appears in COMMON NAMES, and is statically 

6 linked to field identifier "company" in USER PROFILE, which contains value "Acme" and 

7 is also linked to three fields in HISTORY. The linkages between field identifier "firm" in 

8 HISTORY and the field identifier "company" in USER PROFILE (and thereafter to 



9 "firm_name" in COMMON NAMES) could be created by noting that the value "ACME" 

10 appears as a field value in both files. Alternatively, the linkages could be determined by 

11 noting that the field identifier "firm" in HISTORY is similar to the field identifier 

12 "firrnname" in COMMON NAMES. 

13 In one embodiment, heuristics function 601 suggests a previously used value based on 



14 priority of data source. In this embodiment, a high priority can be associated with file 

1 5 HISTORY, such that a field identifier that matches a previously used field identifier appearing 

16 in the history file is suggested first. Different priority levels can be associated with the other 

17 data stores, so that matches from those files can be suggested if there are no matches at the 

1 8 higher priority levels. Alternatively, all possible matches can be suggested from any of the 

1 9 data files, arranged in priority order. Where multiple matches exist in HISTORY, a previously 

20 stored field value that is from the same URL would normally be suggested as a first choice 



2 1 over matches from different URLs. 

22 Few web sites currently use the vCard schema, and it is unlikely that all text boxes on 

23 most web sites can be easily changed to refer to the vCard fields. In order to achieve various 

24 benefits of the invention while minimizing the effort involved, an additional attribute can be 

25 added to the input tag for a form field to identify the field as follows: 

26 <input type="text" name= ,, email ,? VCARD_NAME= M vCard.email"> 

27 In this manner, the site can simply add the VCARDNAME attribute to gain the 

28 functionality of the present invention without re-coding. For example, assume an existing 

29 form has an input field <input type = "text" name = "email">. One way to exploit the 

30 automatic suggestion feature would be to change the coding of the input field to: <input type 

B&W 3797.77746 - MS 124220.1 

19 




1 = "text" name- VCard.email">. Unfortunately, this change may also require changes to script 

2 on the page and on the server, which assumes that the field is still named "email". One 

3 variation of the inventive approach introduces a new attribute VCARD_NAME which allows 

4 the author to explicitly express the mapping of the field to the standard vCard naming without 

5 requiring recoding of logic that depends on the "name" attribute. In effect, the VCARD 

6 attribute provides a "union" function, so that the set of possible completion values can come 

7 not only from the set of values previously stored for the field, but also from an explicit set of 

8 values reference by the attribute. Two fields that have different names can be "forced" to be 

9 correlated for suggestion purposes by adding the same vCard attribute to each of them. 

10 Field values can also be associated across different fields by context through the use 

1 1 of data file FIELD CORRELATORS. For example, if a user fills out an on-line catalog order 

12 specifying his name, address, and zip code on a single form, an indicator can be set indicating 

13 that those values are probably related (i.e., they were supplied on the same form). As shown 

14 in FIG. 6, for example, form "A" from a first web site included field identifiers "name," 

15 "address", and "company", suggesting that these fields were related in some context. A 

16 different form "B" at a second web site included field identifiers "username", "address", and 

1 7 "firm", suggesting that those fields were related in another context. Upon visiting a third site 

18 containing one of these fields, heuristics function 601 can search through file FIELD 

19 CORRELATORS for a similar context in order to provide previously used values. The basic 

20 idea is to extend the "union" function by clustering known common field names. 

21 One technique for correlating field identifiers to previously used field values is through 

22 the use of Bayesian inference techniques. The well-known Bayes' theorem states that the 

23 probability that an event A occurs given that another event B has already occurred is equal to 

24 the probability that the event B occurs given that A has already occurred multiplied by the 

25 probability of occurrence of event A and divided by the probability of occurrence of event B. 

26 Using such techniques, inferences can be drawn regarding fields that frequency appear 

27 together on a form. As one example, suppose that field identifiers for username, password, 

28 and e-mail fields frequently appear together on a form, and generally appear in that relative 

29 order on a web page. (This can be detected either automatically or pre-set by a human 

30 programmer). Then, suppose that a new form is presented that contains field identifiers 
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1 "username", "password", and "mail." Using Bayesian techniques, one could infer that the 

2 third field "mail" is the same as the e-mail field on the other forms, and could suggest 

3 previously used e-mail values for the "mail" field. 

4 There are many different ways of storing previously used field values and mappings 

5 among values. When a form is submitted to a web site, the field identifier, time, and field 

6 value can be stored, indexed by the field identifier. A secondary data store, indexed by URL, 

7 can also be updated. The data store is preferably encrypted and stored in a protected area on 

8 the client computer. In addition to those files shown in FIG. 6, data regarding field names can 

9 be extracted from an address book maintained by the operating system (containing user 

10 registration information); from a "wallet" data store that contains address, name, and credit 

1 1 card information for user; or a "passport" data store that contains information on the user's 

12 country, postal code, date of birth, gender, passport number, photograph, nickname, 

1 3 occupation, and the like. 

14 As with any feature that "remembers" user input, there may be security issues to 

1 5 consider when implementing the principles of the invention. These include (1) ensuring that 

16 web sites can't collect the stored data values entered by the user; (2) making it difficult for 

17 outsiders to get at saved user data; and (3) ensuring that users will perceive that their data is 

18 secure. 

19 As to the first issue, it may be desirable to ensure that any site will have no way to see 

20 the information stored. While the user will see the proposed choices in the pop-down list, it 

21 may be desirable to inhibit storage of any suggested values into the form field data entry 

22 region except as initiated by user action (i.e., pressing a key, hitting the down arrow, or 

23 clicking in the field). A second-click mechanism could also be provided whereby if the user 

24 clicks on a field once, the focus shifts to the field, and a second click shows all completions 

25 for what's in the field. (The second click would not be necessary if the field already had focus, 

26 such as if the tab key had been used). One benefit of this is that a user can fill in forms 

27 without ever touching a key on the keyboard, yet it still requires physical input so that a web 

28 site can't circumvent the feature. 

29 Stored data can be encrypted and stored in protected storage. If the user is logged into 

30 the operating system, the user's password can be used to encrypt the data. If the user has not 
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1 logged into the operating system, then a unique key per machine can be used to encrypt data 

2 in the protected storage area. 

3 It may be desirable to avoid storing for later suggestion purely numeric data values, 

4 such as credit card numbers, PINs or account numbers (the latter examples are typically stored 

5 as text but represent numeric-only values). It is of course within the scope of the invention 

6 to suggest such values. 

7 Several measures can be taken to ensure that users will perceive their data as secure. 



8 Administrators can restrict the use of the features through a browser administration 

9 configuration tool. Additionally, each user can be given a global choice to activate or 

1 0 deactivate the autosuggestion feature, so that field values are never stored when the feature is 

1 1 deactivated (see FIG. 5A). (In one embodiment, the user can be prompted when the user 

12 submits a form, via a dialog box asking the user whether the feature should be turned on or 

1 3 off). Additionally, as outlined above, the user can specify on a per-field basis whether values 

14 for that field should be stored for future use. 



15 It may be desirable to provide web sites with a mechanism for disabling the 

16 autosuggestion feature via script. Some web sites, for example, may perceive it as detrimental 

17 to the operation of their web sites to have field values automatically suggested by a web 

18 browser. An attribute can be set aside to turn off the autosuggestion feature for a particular 

19 field or for an entire form (e.g., <INPUT name = "first name" AUTOCOMPLETE = "off V). 

20 For security reasons, it may be desirable to avoid automatically storing fields 

21 containing numbers, except for those within the vCard schema or those common names 

22 mapped to the schema (e.g., zip codes, and telephone numbers). This is because there is a 

23 chance that a field could represent a credit card number, social security number, bank routing 

24 number, or the like. Numbers probably make up some of the most sensitive data the user 

25 enters in on the web. 

26 Passwords may also require special attention, and can be handled by password 



27 processing function 603. In one embodiment, passwords can be suggested only after a known 

28 username is selected from the drop-down menu. Thus, it may be desirable to remember the 

29 login password of each username on a per-domain basis. The function would consider what 

30 fields exist on a form. If there were a regular edit field and a single password field, it is 
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1 probably a login page. When the user enters a username and password, he can be prompted 

2 by the browser to store or not store the password (see FIG. 5B). The user could also be 

3 prompted once per URL per username/password. In other words, if a user visits a web site 

4 and enters a username/password, the user would be prompted to indicate whether that 

5 username/password should be stored for future use. The next time that user visits the same 

6 web site, he or she would not be prompted again. If a different user visits the same site and 

7 enters a different username/password, they would be prompted to indicate whether that 

8 username/password should be stored for future use. 

9 In one embodiment, when a user selects a suggested item for a username field, 

10 password processing function 603 automatically and immediately fills in the associated 

1 1 password field with the password that was last used (and stored) with that username on that 

12 specific form. (The latter feature can also be implemented by associating the password value 

1 3 with the username without matching on the specific form). Requiring a match on the specific 

14 form (identified by the URL) can prevent an unscrupulous web site operator from stealing the 

15 user's password via a "trojan horse" attack; i.e., impersonating the legitimate site which 

16 requires a username and password and waiting for the user to fill in their username, which 

1 7 would thus fill in a passsword field (possibly hidden), which is then available to the imposter 

18 site. Matching on the specific form ensures that the password is automatically filled in only 

19 on the legitimate site. As described previously, it is contemplated (but not critical) that 

20 passwords are hidden with asterisks or the like, such that a list of passwords cannot be easily 

2 1 viewed. Due to security issues with remembering passwords, a preferred embodiment requires 

22 user confirmation before remembering and associating a password with a particular username 

23 and form. 

24 In addition, a checkbox can be provided to avoid prompting again for this feature. The 

25 action that results from the various combinations of inputs are: 

26 Yes, unchecked: Remember password for this login (based on URL) and ask again in 

27 the future about passwords. 

28 No, unchecked: Do not remember password for this login (this is the default action), 

29 but ask again in the future. 

30 Yes, checked: Remember password for this URL but don't show this window again. 
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1 No, checked: Do not remember and don't ask again. (However, any previously 

2 remembered passwords will still be filled in automatically) 

3 Unless the user checks the "don't ask again" choice, the window will appear for each 

4 new login encountered. This includes a new user logging in to the same URL. For security 

5 reasons, it may be desirable to avoid having a "Yes to all" counterpart, since that would 

6 indicate that passwords are stored without warning, and unknowing users could compromise 

7 their passwords without even knowing it. 

8 When passwords are changed, additional processing may be required. In one 

9 embodiment, software can detect when a different password has been entered for a username 

10 already in the database. The user will be prompted if they want this password changed via a 

1 1 dialog, such as: "The password you entered is different from the one previously stored; would 

12 you like the new password to be stored for future use?" 

1 3 Additional precautions can be provided to protect passwords against "spoofing," such 

14 as might occur if a web site attempted to spoof a login page and extract a password after a user 

1 5 name is selected from the drop-down list. In one embodiment, a URL match is required, such 

16 that if the URL does not match, no passwords will be suggested. Additionally, passwords are 

17 preferably encrypted and stored in protected storage, such that someone with physical access 

18 to the machine cannot gain access to them. Moreover, when filling in a password from a 

1 9 suggestion list, it may be desirable to hide the password with asterisks or a similar mechanism. 

20 A password can be stored in the name-indexed data store in pages where the user 

21 completes a field with t}*e <input=password> tag. In addition to linking that password to an 

22 URL in the data stpr^, the password can also be linked to form information in the base URL 

23 (i.e., in Addition to storing form information for the page 

24 https://w\\^mazon.com^ also link to the base 

25 URL, ht^s://www.amazon.com/). That URL should be checked for passwords. Also, a check 

26 shomd be made to determine whether the user has decided not to save encrypted pages to the 

27 cache. 

28 Where there are multiple users, it may be desirable to prevent one person from using 

29 another's passwords. One approach is to require each user to only remember a single 

30 password, and that password would give the user access to all the passwords they use while 
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1 browsing the web. When a page is first loaded with a tag <input type=password>, a "login" 

2 dialog can be presented. Once the user has logged in, the user has been identified and all 

3 further data fields can be automatically suggested. When the user exits the browser, login 

4 information is lost and the user would need to log in again. A global login procedure could 

5 also be provided for the feature (e.g., explicitly login to the browser to turn on the feature). 

6 Credit card information may also be subjected to special handling. A malicious web 

7 site could generate an input field with an innocuous name like "FirstName" while labeling it 

8 "Credit Card Number." An unknowing user may then enter their credit card number, which 

9 would then be saved and offered for autosuggestion whenever an input field named 

10 "FirstName" is encountered. This could critically affect the perceived privacy of the inventive 

11 principles. To prevent this, a checksum can be performed on field values that are integers. 

12 One possible checksum algorithm is as follows: 

13 For a card with an even number of digits, double every odd numbered digit and 

14 subtract 9 if the product is greater than 9. Add up all the even digits as well as the doubled odd 

15 digits, and the result must be a multiple of 10 or it's not a valid card. If a card has an odd 

16 number of digits, perform the same addition, doubling the even numbered digits instead. 

17 Since cards can have varying numbers of digits (i.e. Visa has 13 or 16, Amex 15, and 

18 MC 16), the fields can be filtered on a minimum of 10 digits. This will prevent the software 

19 from catching zip codes with the checksum. If the field value is a credit card number, then 

20 storage of the field for future use can be suppressed. 

21 The foregoing explanation includes many variations and embodiments, and the 

22 invention is not intended to be limited to the specific details disclosed herein. Consequently, 

23 the invention is limited only by the claims appended hereto. 
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